In today's complex computer-program and networking environments, code sharing, scalability, and integration with other cross-platform frameworks are generally desired. Use of a runtime by a hosting application (i.e., hereinafter often referred to as a “host”) generally allows application developers to write managed code with cross-platform compatibility, increased scalability, a common type system, multiple-language support, automatic memory management, and so on. Runtimes include, for example a Common Language Runtime (CLR), a Java Virtual Machine (VM), and/or the like.
Most hosts consist of both managed code and unmanaged code. Managed code is code that executes under the control of a runtime. Conversely, unmanaged code is code that runs outside of the runtime. Common object model (COM) components, ActiveX® interfaces, and WIN32® API functions are examples of unmanaged code. Unmanaged hosting code is used by a process to configure a runtime, load it into the process, and transition the process into managed code.
Once the process, which includes the host and the runtime, is executing, integration between the host and the runtime in the execution environment is very limited and basic. Other than the described interactions of configuring, loading, and transitioning the runtime by the host, the host will typically only direct the runtime to perform a specific task, and/or receive an event/message from the runtime that a particular runtime task has completed. Thus, the host and the runtime are essentially separate, non-integrated entities of the process. This means that a hosting application has little or no control over many of the services provided by the runtime.
Relying on hosted runtime service(s) when the host expects use of its own service implementation can be problematic, and may even break the host application's expected performance, results, and/or the like. For instance, the host may have tuned specific threading, memory, synchronization, and/or security implementations over time, for example, for improved scalability and performance. Thus, although the host may desire the benefits of a runtime (e.g., cross-platform compatibility, reduced coding efforts, etc.), the host's specially tuned implementation may be incompatible with corresponding runtime services. In such a situation, the host may only load a runtime that relies on host-supplied services, or may completely bypass runtime services altogether by directly accessing underlying OS services. Such work-around(s) do not allow application designers to leverage the benefits that runtimes were designed to provide, resulting in less integrated and portable products.
Accordingly, systems and methods to increase execution environment control between a host and a runtime are greatly desired.